kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19980424-19980901/000114_news@newsmaster….columbia.edu _Fri May 22 10:40:52 1998.msg

Internet Message Format | 1998-08-31 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA18531
    for <[e-mail]>; Fri, 22 May 1998 10:40:51 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA25128
    for kermit.misc@watsun; Fri, 22 May 1998 10:40:50 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Kermit on the HP48 (Was: One-Way Transfer)
Date: 22 May 1998 14:40:45 GMT
Organization: Columbia University
Lines: 108
Message-ID: <6k42pd$a3m$[e-mail]>
References: <[e-mail]> <6k1qoj$d92$[e-mail]> <[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8767 comp.sys.hp48:81320

In article <[e-mail]>,
Skip Collins  <[e-mail]> wrote:
: [e-mail] (Jeffrey Altman) writes:
:
: > The HP48 can not handle 9600 baud transfers without flow control
: > Turn on XON/XOFF flow control on the calculator and SET FLOW CONTROL
: > XON/XOFF on K95.
:
: The HP48 Kermit can handle 9600 baud transfers in both directions
: without flow control. I do it all the time. In fact, the calculator
: will automatically _disable_ flow control for Kermit transfers even
: when it is enabled for other serial I/O (I think). There is a 255
: character input buffer. The bare bones Kermit on the HP48 does not
: implement long packets so the buffer is plenty big to handle Kermit
: packets without flow control.
:
: Last month there was an interesting discussion about the limitations
: of HP48 Kermit on comp.sys.hp48. Search dejanews for Dan Kirkland's
: posts with the subject "Re: a better kermit". Due to a basic flaw in
: the HP ROM kermit, throughput in receiving is slower than it should
: be. Perhaps someone will reimplement the binary receive routing to
: overcome this problem.
:
: As for the original poster's problem, I have no idea. Perhaps he
: should try mskermit. I works for me.
:
Thanks for the comp.sys.hp48 reference.  I'm copying this response to that
newsgroup.

As noted in an earlier posting in this thread, I would like to straighten
out the massive confusion about Kermit file transfer with the HP-48.  We (at
the Kermit Project) are not HP-48 experts, but we do have an early model
HP-48 for testing.  When we get complaints or questions about file transfer
with the HP-48, we check our answers on it.

But we usually find that what works for us fails to work for others, or vice
versa.  No doubt because there are many and varied HP-48 models, ROM
versions, etc etc.

I would like to set up an HP-48 resource at the Kermit web site where all
HP-48 users could look to find answers to frequently asked questions, hints
and tips, etc.

To that end, first let me suggest that all postings to comp.sys.hp48 be
copied to comp.protocols.kermit.misc so that people who might know more
about the Kermit program on the other end can help out.

Second, a few points of clarification on recent comp.sys.hp48 postings:

 1. Kermit is not a slow protocol.  The HP-48 implementation of the Kermit
    protocol is slow.  It was written by HP (or whoever HP hired to do it)
    without our knowledge or advice.  For an analysis of Kermit protocol
    performance, see:

      http://www.columbia.edu/kermit/newsn6.html#perf

 2. Whatever Kermit software might have been provided to HP-48 users by
    HP is not necessarily appropriate.  Current versions of Kermit software
    are found at the Kermit Project website:

      http://www.columbia.edu/kermit/

Let's see if we can set up a simple set of guidelines for how to set up
Kermit software (on DOS, Windows, UNIX, etc) for communicating with the
HP-48, or for each model thereof, when the models make a difference.

 1. The top serial speed is 9600, right?

 2. Should the flow control setting be NONE or XON/XOFF?  We have
    conflicting reports (see above).  Obviously the HP-48 *should* be
    exercising some form of flow control, but some reports indicate that
    it does not (even if it is set to do so).

 3. Is the link transparent to incoming control characters?  Can the
    client Kermit program use control-character unprefixing when sending
    to the HP-48?  If not, the client program must be told to
    SET CONTROL PREFIX ALL prior to sending files to the HP-48.

 4. Does the link allow 8-bit data?  If not, the client must be given
    the appropriate SET PARITY command.

The HP-48 does not support long packets; thus the maximum packet length
is 94, but this should be negotiated automatically.

The HP communication port is half duplex, meaning that data can go in both
directions, but only in one direction at a time.  Therefore sliding windows
can not be used (this too should be negotiated automatically).

More to the point, I have also heard that (at least some models of) the
HP-48 become "deaf" to incoming bytes for some number of milliseconds while
switching their serial port from "send" to "receive", so if the client
program is too fast, file transfers can fail.  The solution to this is to
tell the client program to pause for a sufficient number of milliseconds
prior to sending each packet:

  set send pause 100 ; or whatever number works

Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
"parses" incoming text-mode material on the fly, and appends the material
from each incoming packet to a "string", resulting in a steadily
deteriorating transfer rate, at least up to some point at which the HP-48
dumps the string to storage and starts over with a new string.  There's not
much that the Kermit client can do about that.

Any other hints from HP-48 users will be appreciated; I'll be glad to
collect them into an FAQ.

- Frank